Cream of the Crop 1

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP040592.ARJ / 04-05-92.TPC

Wrap

Text File | 1992-04-05 | 69KB | 1,891 lines

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-30-92 01:54:23 From Trevor Carlsen To Joseph Crea Subject Re: Obsolete Pascal?? JC> ... I have used Doug Cooper's _Standard Pascal User JC> Reference Manual_ (published by W. W. Norton & Co., ISBN JC> 0-393-30121-4) extensively and can recommend it highly. Thanks. I've not seen this and will try and purchase it immediately. Do you know if it contains full details of the proposed ANSI standard? The copy I ordered from Global Engineering Documents (thanks Scott) has so far failed to materialise. JC> ... Contrary to your statements, an 'absolutely "standard"' JC> compiler can be commercially viable since the Standard does JC> not disallow extensions ... Fair comment. However to be more accurate what I really meant was that I do not believe that it is commercially viable to program using only standard Pascal. I accept that a compiler that will compile stock standard code can be commercially viable because of its extensions to the language. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/03/30 19:27:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-30-92 02:03:58 From Trevor Carlsen To Joy Mukherjee Subject Entry To competition JM> Wasn't the item entered supposed to be a unit that could JM> essentially be used by any program and still serve a useful JM> purpose? Something like a unit which calculated the running JM> time of the program or what not? If not, I'd like to submit JM> my CLMR which is just a program to read QWK messages of more JM> than 150 lines. It was for any hint, unit, program that was useful. As I no longer have CLMR on my base please netmail it to me. BTW, even though I usually try to read all messages in this conference, time constraints make it impossible at times - I will be absent again for a few days later this week - and if you spell my name incorrectly I can easily miss your message as my reader/editor looks for messages with my name somewhere in the header and/or text. (No 'O' in Carlsen :-)). TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/03/30 19:27:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-30-92 07:54:56 From Dj Murdoch To Harald Harms Subject Re: Need help on TPU files. HH> Saesoft (R) [E]Turbo Pascal TPU [C6]Convertor - Version 1.01 HH> Copyright (C) Saesoft International 1983 - 1992. All rights reserved. HH> Registered to: Harald_Harms HH> Warning! This utility works with most TPU-s, this does NOT mean that HH> a converted TPU will perform correctly, this utility overrides that HH> what should not be overridden and such a TPU may blowup if the internal HH> library code pointers are invalidly linked with non-standard TPU-s. But what does it do? They're asking for $20, sight unseen, and they're not even clear as to what they're claiming the product will do. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/03/31 11:11:07 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 15:21:41 From Trevor Carlsen To Jud Mccranie Subject constants in Pascal JM> This brings up a point about how Pascal handles constants. Should JM> they be changable or not in the body of the program? There are some JM> arguements either way. Making them not changable is safer, making JM> them changable is more convienent. Would it be nice to have both JM> kinds? Maybe. In TP (at least) you can change the contstant in JM> the body if and only if you give it a type. This is a way to JM> distinguish between the two kinds. Unfortunately, in some cases you JM> must give a type to tell it what you want. In TP at least we have the best of both worlds, although to be realistic the typed constants are really only initialised variables. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/03/31 20:20:26 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 15:26:36 From Trevor Carlsen To Jud Mccranie Subject Re: Power of assemb vs Pascal TC> As assembler is so low-level, recursion is handled by the TC> programmer and the stack is used. As this is exactly what is TC> happening anyway, it is no different, and no more difficult, TC> than normal assembler programming. JM> But it is more difficult than doing it in a more powerful language. You get points for trying but that's about all! :-) TC> Your assembly "programmer" friend is obviously not very TC> competent in programming. JM> He's probably the second best programmer I know personally. (He is JM> not the one who asks why not allow conditionals at the top and bottom JM> of the loop.) He makes a ton of money - several times as much as I JM> do... MMmmm... Programming ability and money making ability from programming are not necessarily synonomous! TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/03/31 20:20:26 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 15:43:08 From Trevor Carlsen To Greg Smith Subject Pascal 6.0 GS> After looking over the algorithms, it seems that an array would be GS> quicker for most applications, but when you're sorting a doubly linked GS> list of 1-2k structures, it's much more efficient to move a couple 4 GS> byte pointers around than it is to move the full structure. I agree but you do not need a linked list to do that! TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/03/31 20:20:26 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 15:44:39 From Trevor Carlsen To Tony Mann Subject Sets TM> Okay, the S.Flag has to be evaluated as a Boolean. Its very easy TM> to evaluate them as follows: TM> If NotValidated in S.Flag then Writeln('The file is not Validated') TM> else Writeln('The File is Validated'); TM> Now if you want to change the validated status of the TM> file just create a new set adding or omitting the TM> NotValidated as follows: TM> NewFlags:=FlagRecSet; TM> NewFlags:=(OwnerRestricted, UUF6, UUF5, UUF4, UUF3, UUF2, UUF1); TM> If NotValidated in S.Flag then S.Flag:=NewFlags; TM> This crude example would then validate the file, since TM> "NotValidated" is no longer in the FlagRecSet. To TM> unvalidate the file just create a new FlagRecSet TM> containing NotValidated. The above is unnecessary. To delete NotValidated from S.Flag - S.Flag := S.Flag - [NotValidated]; to add NotValidated to S.Flag - S.Flag := S.Flag + [NotValidated]; TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/03/31 20:20:26 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 16:35:31 From Trevor Carlsen To Sysop Subject Rules of this echo Would all sysops please ensure that a copy of these rules is available to all users of the echo. It suggested that they be made a protected message to ensure that normal message area housekeeping does not not result in them being deleted. There are some important changes this month relating to off-topic messages and the use of aliases. RULES OF THE PASCAL ECHO The Pascal echo is an internationally distributed FidoNet echo devoted to the discussion and promotion of the Pascal programming language in all its variations. Countries currently participating include the USA, Australia, Canada, The Netherlands, Denmark, Sweden, Norway, Finland, Belgium, Germany, Austria, Poland, USSR, Israel and occasionally Singapore. MODERATOR. The currently appointed Moderator is Trevor Carlsen. He can be reached by Netmail at 3:690/644 or by normal postage by writing to - Trevor J Carlsen Post Office Box 568 Port Hedland Western Australia 6721 Phone (voice) +61 91 73-2026 (Local time is GMT+8) (data) +61 91 73-2569 RULES. 1. Leave moderation to the moderator. Self appointed "echo policemen" only waste echo space and create ill-feeling. 2. NO FLAMING. If you feel that you have been insulted in some way by somebody, you have three options. (a) Complain by netmail to the person concerned. (b) Bring the matter to the moderator's notice - again by netmail. (c) Ignore it. (the preferred option!) 3. Person-person messages that are not of general interest to other users are STRICTLY not permitted. Netmail these types of messages. 4. When replying to messages try and do so "off-line" and quote some of the message being replied to. However don't go overboard with quoting. Quote just enough to enable the context of the reply to be fully understood and in particular DO NOT INCLUDE PARTS OF THE TEAR AND ORIGIN LINES. 5. When replying to questions with code examples, test them where possible by compiling and running them (or state that you have not done this). If possible always quote manual references, text references etc. If your code example contains inline code then it is only fair that you FULLY comment such code so that users can determine the validity or viability of that code BEFORE risking it on their own machines/data. 6. If replying to a question where you are disagreeing with the other person's code or statement/s, support your viewpoint with working code examples or valid text references. This will be more productive than unsupported statements. If you are not prepared to do this then don't reply in the first place! 7. Do not ENTER or REPLY TO off-topic messages. The subject matter is Pascal. Discussions on religion, politics, copyright, other programming languages and personal messages are OFF-TOPIC. Any subject that is illegal or undesirable in a responsible conference - eg discussion or tips on producing viruses or how to illegally obtain access to information that the user is unauthorised to obtain is off-topic and will be severely dealt with. Sometimes messages from other conferences become linked into another conference due to faulty software. Replying to, or commenting on, such messages is not permitted. The main point is to use common sense. Some light hearted banter can relieve the formality and brighten up ones day but do not carry this to the length where it becomes an extended thread. The object of the echo is to help, get help and enjoy communicating with like-minded people. 8. No "thank-you" or "no content" or "rubbish" messages. Sysops spend a great deal of time and money to enable the distribution of echoes such as this. Please respect this and avoid messages such as "Thank you. Just what I needed" or "I agree" etc. By observing this etiquette you will be helping to ensure greater participation in the future. 9. All messages are to be in the English language and must be in PLAIN TEXT. No encryption of any kind is permissable as this is in direct contravention of FidoNet policy. This also means that binary file transfer by conversion to asciiz is not allowed. 10. Limited, low key, on-topic advertising is permitted. The key words here are ON-TOPIC and LOW KEY. Please restrict any notices to a "one-time" issue and keep it brief and informative with NO SALES HYPE. Any notice must be of interest to the echo participants in general. Therefore this excludes such items as job vacancies, BBS ads, for sale notices and similar as this is an International echo. 11. When seeking assistance - a) If Turbo Pascal is your language, place the cursor on the key word and call the on-line help (Ctrl-F1 in the IDE) to see if the answer may be there. b) Double check the manual to see if the answer is there. c) When writing the message include enough code to allow would-be helpers to have a chance to determine what the problem might be. If possible condense the problem into a tiny working example and post that. d) This is a high volume echo so use a subject line in the message that is likely to gain attention from the experts who are often too busy to read every message. "Help wanted" or similar is a good way to be ignored. Something like "Exec procedure not working" is better. e) Remember that a reply of "RTFM" is not considered or meant as an insult. In fact it is considered a polite (in spite of the connotations) way of reminding someone that the answer they seek is in the manual. f) Remember also that your reply may come from anyone, of possibly unknown skill level. Don't be too upset if misled as it is probably unintentional and will almost certainly be corrected by another reader. 12. When offering advice or help - a) Do so in a helpful, polite manner. Don't be condescending - not everybody may have your experience or skills. b) Refer to the page in the manual where the answer is if your answer is "RTFM"! 13. Messages should comply with the FidoNet message requirements. Origin lines should not exceed 79 characters, tear lines must not exceed 25 characters and messages should not contain any "hi-bit" (characters with an ascii code over 127) characters. No encrypted text is permitted. Messages are to be under 150 lines in length. Any suggestions re alterations to this message are welcome. Please make such suggestions by netmail. --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/03/31 20:20:26 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 16:40:45 From Trevor Carlsen To All Subject Contest $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ In order to promote both this echo and the use of Pascal as $ $ an all purpose language, I have decided to offer a prize of $ $ two hundred and fifty dollars (Aust.) to the contributor $ $ who sends me the most useful utility/hint/program/unit by the $ $ 30th June 1992. There will be a second prize of one $ $ hundred dollars, and a third prize of fifty dollars. $ $ $ $ Conditions: $ $ $ $ All entries are to be submitted either on a 5.25" or 3.5" $ $ disk or by crashing the file direct to my node. All source $ $ code must be included and must be expressly released into $ $ the PUBLIC DOMAIN. No copyright material will be accepted. $ $ Entries are to be in the Pascal programming language, but $ $ may contain in-line machine code or external routines. If $ $ this is the case, full source code, as comments and a ready $ $ include .OBJ file with assembler source MUST be included. $ $ Generally pure Pascal code will receive higher marks! $ $ All material is to be for the MS-DOS (or compatible) $ $ programming environment. $ $ $ $ All material must have full details of the author's name, $ $ address and, if possible, a telephone number for voice $ $ contact. $ $ $ $ The sole judge and arbitor will be myself and the best of the $ $ entries will be posted in the echo on a progressive basis. $ $ The ten finalists will be re-posted and echo participants $ $ invited to vote to determine the eventual winner. $ $ $ $ Entries should be submitted to $ $ Trevor J Carlsen $ $ PO Box 568 $ $ Port Hedland $ $ Western Australia 6721 Phone (voice) +61 91 73 2026 $ $ $ $ no later than 30th June 1992. The final selection will take $ $ place during July 1992. If a minimum of twenty valid entries $ $ are not received by the due date the contest will be nul and $ $ void. $ $ $ $ The media (disks etc) that entries are submitted on will $ $ become my property unless $2.50 (Aust) (approx US$2.00) is $ $ included for return postage. $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/03/31 20:20:27 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 08:17:45 From Dj Murdoch To Terry Hughes Subject TurboPower and TPW TH> Finally, we certainly could do TV add-ons to attract new TH> programmers that want such tools. However, our resources are TH> finite and we've been concentrating our efforts on new tools for TH> Turbo Pascal for Windows. Could you let us know the current status of those? I haven't been keeping track of your announcements. All I remember is that you were intending to port B-tree Filer first. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/01 09:25:25 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 08:20:31 From Dj Murdoch To Jud Mccranie Subject Re: Power of assemb vs Pascal HH> Recursion in asm works fine, you just have to make sure you HH> know what's on the stack... JM> But in Pascal you don't have to worry about that. Programmers JM> shouldn't have to fret over details that the compiler can handle. You have exactly the same worries in Pascal as in Assembler, just under differen names. In Assembler, you need to be sure your variables are in a local stack frame, in Pascal you have to make sure they're local variables. If you try to do recursion with all your variables global in Pascal you'll mess up just as badly as you would in Assembler. There are many good reasons to prefer Pascal over Assembler, and many good reasons to prefer Assembler over Pascal. Each has its own domain. Since you've never learned Assembler, I'd say the only thing you're qualified to say about it is that the learning curve looks steep. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/01 09:25:25 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 08:24:54 From Dj Murdoch To Jud Mccranie Subject Re: constants in Pascal JM> This brings up a point about how Pascal handles constants. Should JM> they be changable or not in the body of the program? There are some JM> arguements either way. Making them not changable is safer, making JM> them changable is more convienent. Would it be nice to have both JM> kinds? Maybe. In TP (at least) you can change the contstant in JM> the body if and only if you give it a type. This is a way to JM> distinguish between the two kinds. Unfortunately, in some cases you JM> must give a type to tell it what you want. This is a real kludge, but one that's been in TP so long that I don't think there's much hope of a fix for it. Constants should be constant, absolutely unchangeable by legal code. The current "typed constants" should have been implemented as initialized variables, and it would be less embarrassing to explain your code to people who don't know TP. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/01 09:25:25 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 08:31:02 From Dj Murdoch To David Solly Subject Re: Chr/Char interchange? DS> I was wondering if this is something particular DS> to Turbo Pascal or a bug in the compiler. DS> Encipher := CHAR(c + Offset); {offset := 64} DS> I believe the second last line should have read: DS> Encipher := CHR(c + Offset); That's a TP peculiarity. TP allows typecasting. It happens that typecasting is approximately what CHR does. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/01 09:25:25 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 03-31-92 22:36:52 From Dj Murdoch To All Subject STREAM11.ZIP: Stream extensions unit I just hatched my STREAMS unit to the PDN Pascal file echo - twice! The first time, I forgot to include the compression code, so it wouldn't compile. If you have STREAM10.ZIP, please erase it; STREAM11.ZIP is what you should be using. There aren't any changes since I previewed it on Friday; here's the object hierarchy that it provides: TStream (from Objects) TFilter Base type for filters TEncryptFilter Encrypts as it writes; decrypts as it reads TLZWFilter Compresses as it writes; expands as it reads TTextFilter Provides text file interface to stream TLogFilter Provides logging of text file activity TRAMStream Stream in memory TDOSStream (from Objects) TBufStream (from Objects) TNamedBufStream Buffered file stream that knows its name TTempBufStream Buffered file stream that erases itself when done It also has a few procedures and functions: TempStream allocates a temporary stream OvrInitStream like OvrInitEMS, but buffers overlays on a stream May be called several times to buffer different segments on different streams. OvrDetachStream detaches stream from overlay system OvrDisposeStreams detaches all streams from overlay system and disposes of them OvrSizeNeeded Calculates the size needed to load the rest of the segments to a stream OvrLoadAll immediately copies as many overlay segments to the stream as will fit It's free, for noncommercial use. Look for it soon on a PDN Pascal node near you! --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/01 09:25:25 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-01-92 14:15:12 From Trevor Carlsen To All Subject My absence again... I will be absent from the echo again until at least Mon 6th. Enjoy! (I try to avoid the "big smoke" as much as possible but sometimes it is unavoida le :-) Hopefully I'll finish my business by Sat evening, relax at the footy on Sun and catch the early AM "red eye special" flight back Mon. [That's PLAN "A"] ) Moderator. --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/01 19:41:33 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-01-92 08:04:59 From Dj Murdoch To Greg Williams Subject Re: Yet another use for streams DM> There's no restriction on the size of a stream that I DM> can think of, but if you went beyond longint size, all DM> the Seek, GetSize, GetPos etc. methods would fail. DM> Why are you finding the Seek restrictions a pain? Do DM> you really have streams bigger than a longint? GW> Yes, the streams I'm concerned with are GW> Binary-Large-Objects. Doing some experimentation on GW> object databases. The database-search queries return a GW> pointer/path to the object in question, which is treated as a byte-stream. GW> Since there is no requirement to know (or care) about the GW> type or size of the object in question (whether it be a GW> 300K *.GIF, or a 5Mb database itself), it is important not GW> to "shred" the data into many smaller files just to store it. But a longint can handle up to 2 Gigabytes. Doesn't that handle everything for you? GW> When you have a computer with 64 Gb of memory, GW> you wont want to load 40 different files just to get your GW> app's data into memory. It shouldn't be too hard to redefine everything in terms of 64 bit integers instead of 32 bit integers, and that'll push the limit high enough for quite a while. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/02 09:29:56 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-01-92 08:13:15 From Dj Murdoch To Jan Hoolwerf Subject Re: Is this possible in TurboPascal? JH> TYPE JH> OptionsBits = ( JH> Bit0, JH> _b1, _b2, _b3, _b4, _b5, _b6, JH> Bit7); JH> OptionsType = SET OF OptionsBits; JH> Now it's easy to use (test, set, reset) Bit0 and Bit7. So far so good. JH> Q: is it possible in TP to define the bits 1-6 in one JH> 'statement', without spelling them out bit by bit. :-) No, it's not. That's what the "packed" keyword is supposed to do: you could have a declaration something like optionstype = packed record bit0 : 0..1; mid6 : 0..63; bit7 : 0..1; end; and it would all be stored in one byte. Unfortunately, TP ignores packed, and there really isn't any simple way to get at those middle 6 bits. One alternative would be to declare the byte as an object, but that seems a bit of overkill: type optionstype = object data : byte; function getbit0 : byte; function getmid6 : byte; function getbit7 : byte; procedure setbit0(value : byte); procedure setmid6(value : byte); procedure setbit7(value : byte); end; etc. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/02 09:29:57 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-01-92 08:20:16 From Dj Murdoch To Peter Kolding Subject Re: Updating TPRO PK> Just unpacked TP6.00, whih has been sitting on my shelf for...what 1 or 2 PK> years?...and find that there has been a change in the PK> FreePtr, i.e. it is no more. Has someone produced code or PK> a program that will 'fix-up' TPRO 5.09 units so that they PK> can be compiled by TP6? Turbo Asynch compiles fine, but I'm PK> used to dealing with TPRO and compile Asynch in the TPRO mode. PK> All help and suggestions gratefully accepted. You could fix it up to compile, but there are several subtle bugs that that would introduce - the deletion of FreePtr isn't the only change from TP 5.5 to 6.0. I'd recommend getting the TPRO update from TurboPower. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/02 09:29:57 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-01-92 22:52:00 From Norbert Igl To Benjamin Lin Subject ABSOLUTE CSEG:$100?? > Recently I came across some source code that I believe was written > for early version of Turbo Pascal contains a line like this > VAR > SIG : BYTE ABSOLUTE CSEG:$0100; > ^ > ---- The cursor stoped here Hi Ben, CSEG is a function ! you say : "it's from an early version" .... ...maybe from 3.0, where CSEG:100 means the start of a .COM-file? you'd better forget about this in TP-Versions >= 4.0 ! Bye from Germany, Norbert --- * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3) * Tossed by SFToss v1.00b on 92/04/03 04:32:45 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-01-92 09:43:00 From Terry Hughes To Randy Blackmond Subject B-Tree m/u RB>Yes, everything you listed has been checked and verified. RB>NETDEMO runs fine, SHARE is loaded only on the server, MsNet RB>is the net type being used and I am passing a workstation RB>number as a command line parameter. I was going to recompile RB>NETDEMO and see if I got the same error my program gave, but RB>was unable to do so since NETDEMO uses TPRO and I have OPRO... RB>I'll follow your last suggestion and make a bare bones RB>program to try and isolate things a little bit. Will get RB>back to you with my results. Thanks. You can also use SIMPDEMO, which doesn't rely on any other units, as a test bed. -Terry * OLX 2.2 * TurboPower Software (voice 719-260-6641) --- Maximus 2.01wb * Origin: The Programmers Playhouse (1:128/60) * Tossed by SFToss v1.00b on 92/04/04 10:05:58 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:09:02 From Terry Hughes To Richard Nelson Subject Re: Why I Like Tp 5.5 Id RN> > Thanks. OPRO was voted one of eight, I think, programmer RN> > productivity tools to receive Computer Languages Product RN> > Excellence awards for 1990. RN>Of course, in fairness, one of the others receiving that RN>award was Turbo Vision.... :-) TV didn't get the same award as OPRO. OPRO, TV and about 38 other products all got Productivity Awards. OPRO and about seven others were singled out of that group and given Product Excellence Awards. However, the Productivity Award is also a fine achievement and something you should be proud of (I say that since APRO just won a Productivity Award this year <g>). RN>I think we reached a detente on this a year or so ago. I was asked to comment so I did. -Terry * OLX 2.2 * TurboPower Software (voice 719-260-6641) --- Maximus 2.01wb * Origin: The Programmers Playhouse (1:128/60) * Tossed by SFToss v1.00b on 92/04/04 10:05:58 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-01-92 10:24:04 From Terry Hughes To Peter Kolding Subject Updating TPRO PK>Just unpacked TP6.00, whih has been sitting on my shelf for...what 1 or 2 PK>years?...and find that there has been a change in the PK>FreePtr, i.e. it is no more. Has someone produced code or PK>a program that will 'fix-up' TPRO 5.09 units so that they PK>can be compiled by TP6? Turbo Asynch compiles fine, but I'm PK>used to dealing with TPRO and compile Asynch in the TPRO mode. Unfortunately, the changes are far too involved to describe in a message or even an update file. Best bet is to spend $20 and get the latest version from us. You can call at the number below or 800-333-4160 from the US and Canada. -Terry * OLX 2.2 * TurboPower Software (voice 719-260-6641) --- Maximus 2.01wb * Origin: The Programmers Playhouse (1:128/60) * Tossed by SFToss v1.00b on 92/04/04 10:05:59 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:41:06 From Terry Hughes To Dj Murdoch Subject TurboPower and TPW DM> TH> Finally, we certainly could do TV add-ons to attract new DM> TH> programmers that want such tools. However, our resources are DM> TH> finite and we've been concentrating our efforts on new tools for DM> TH> Turbo Pascal for Windows. DM>Could you let us know the current status of those? I DM>haven't been keeping track of your announcements. All I DM>remember is that you were intending to port B-tree Filer DM>first. B-Tree Filer has been running under TPW for a good while now. In the most recent version, 5.23, we've added TPW support to all the supplemental units (NETWARE, NETBIOS, etc.) As far as new products go, we just posted some rather detailed announcements on our CIS forum that I've hesitated to post here (due to their length). I'll give a real brief overview: The first product is called WinSys. It's a collection of system level and data handling routines like string handling, container classes, large arrays, date routines, sorting and so on. They can be compiled as units or DLLs. We'll be providing C/C++ interfaces as well. And, since this product doesn't depend on OWL it can be used with Microsoft C++ as well as Borland C++ and TPW. The second product is called Data Entry Workshop. It provides custom data entry controls and validated data entry screens akin to OPRO's data entry system. You design the screens in Resource Workshop and then run our MAKESRC utilty to generate source code. We also provide a utility to convert OPRO OPL libraries to resource scripts ready for importing into RW. This product relies heavily on OWL so it will work only with TPW and BC++ (not Microsoft C++). Both will ship this summer. -Terry * OLX 2.2 * TurboPower Software (voice 719-260-6641) --- Maximus 2.01wb * Origin: The Programmers Playhouse (1:128/60) * Tossed by SFToss v1.00b on 92/04/04 10:05:59 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:24:08 From Terry Hughes To Pat Anderson Subject Why I Like Tp 5.5 Ide (c PA> TH> We avoided an event driven architecture for a variety of PA> TH> reasons: steep learning curve, unnecessary complexity and market PA> TH> resistance. Our sales figures, customer feedback and industry PA>Market resistance - I thought so...will you try to tell PA>Jeff Dunteman this?? He keeps saying "Event driven is the PA>way programming is going to be." I think Jeff is a superb writer and teacher and I thoroughly enjoy his PC Techniques magazine and his column in Dr. Dobbs. However, he's not down in the trenches programming for a living so his perspective and priorities aren't always the same as ours. PA>Keep up the good work! Thanks. We'll certainly keep trying. -Terry * OLX 2.2 * TurboPower Software (voice 719-260-6641) --- Maximus 2.01wb * Origin: The Programmers Playhouse (1:128/60) * Tossed by SFToss v1.00b on 92/04/04 10:06:00 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 19:40:00 From Werner Berghofer To Robert Soubie Subject Traffic report Robert, [average message posting frequency per day] > are those referenced to UT time, by correction on > the fidonet zone and net? no, this statistic table simply is composed from the time stamps in the message header. However, if something like a "^aTZ" kludge line could be "standardized" (well, *now* I'm kidding) in Fidonet this would help a lot, for example for correct chronological sorting of a messagebase. By the way: are you aware of any sources or literature describing the defined time zone strings and their respective offsets to UTC? Werner --- * Origin: God is real... unless declared integer. (2:310/90.100) * Tossed by SFToss v1.00b on 92/04/04 10:06:43 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 19:50:01 From Werner Berghofer To Benjamin Lin Subject Traffic report Hello, Benjamin. > Is there source of this file available? If so, can you please > post it [...] I assume some 50+ KB of source code, including references to a lot of units written by myself, would be too much for this echo. It's primarily a mixture of fast, buffered file access methods, some date calculating stuff and the usual way of look-up and inserting into linked lists. The really tricky stuff are the parts dealing with the various forms of f*cking up message topics (Re:, (R) and so on) and the braindead programs widely in use in Fidonet randomly truncating message subjects. Of course I have the ambition to create programs smart enough to find out that messages regarding "Which is better: CP/M 2.2 or OS/2.0?" and "Re: (R): Which is better: CP/M 2.2 or O" originally belong to the same message thread. Werner --- * Origin: God is real... unless declared integer. (2:310/90.100) * Tossed by SFToss v1.00b on 92/04/04 10:06:43 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:19:34 From Dj Murdoch To John Richardson Subject Re: Data Compression Techniques ******** JR> I'm interested in looking at this TPLZW code. I am JR> looking for some data compression routines to work with JR> graphics files (and this sounds appealing). Anybody know JR> where I can obtain this? I finally released my stream version of it. If you can't find TPLZW, look for STREAM11.ZIP, on any PDN Pascal BBS (in particular my bossnode, 221/177). --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/04 10:06:50 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:24:04 From Dj Murdoch To Jud Mccranie Subject Re: Power of assemb vs Pascal JM> But you don't have to specifically manage the stack with recursion in JM> Pascal. It takes care of those bookkeeping details for you. Nor do you with any good assembler. A86, TASM, probably even MASM by now, all manage the stack for you. You just declare that a variable should be local, and it is. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/04 10:06:50 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:27:58 From Dj Murdoch To James Digiacomo Subject Re: Dynamic Arrays JD> I'm trying to use Dynamic arrays in TPv5.5 in the JD> following program. Its works JD> correctly within the IDE but when I compile it to and .EXE JD> file and then run JD> it at the DOS prompt, it somehow appends garbage with the JD> data store within JD> the array. It looks like your dynamic array code is fine, but you forgot to initialize a variable. JD> begin JD> getmem(lim,combo * sizeof(item)); JD> writeln('Im working'); JD> if (take = 1) then JD> begin JD> for count := 1 to combo do JD> begin JD> x := trunc(random(num_elmts))+1; At this point, num_elmts is undefined. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/04 10:06:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:32:41 From Dj Murdoch To Jud Mccranie Subject Re: More features needed in TP JM> More things needed in TP: JM> 1. Long words (32-bit unsigned) JM> 2. Choice of memory models (allowing far data, etc) I can see that 1 would be nice, but I can't see much need for 2. You've already got quite a choice of memory model in TP: Far data: the heap Near data: the stack and data segment Far procedures: the ones in other units Near procedures: the ones in the same unit About the only thing missing from TP in the way of memory models is the near pointer, which to be useful forces your stack and data segment to be the same. That would help make small programs even smaller, but isn't any use in the big programs that would really benefit from improvements. On the other hand, compilers with multiple memory models end up taking up huge gobs of disk space, because you need a different library for every model. Any time I've owned one I just instructed the installation program to dump every model but one. If Borland is listening, I hope that they *don't* put multiple memory models into the next release. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/04 10:06:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:42:51 From Dj Murdoch To Daniel Torrey Subject Re: Turbovision - Off Topic? DT> Is TurboVision off-topic in here yet? In any case, are there any DT> sysops in here interested in starting a TurboVision echo? I've never heard any suggestion that TV should be off-topic, and I'd object if there was one. There's no need to split up the echo. TV is a library that most people using Pascal have access to (since the majority of people using Pascal on any platform are using TP 6.0 on a PC). If you're having trouble finding the TV messages amid all the other clutter, write a better message reader. I'd love to see a good one written in TV. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/04 10:06:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:46:53 From Dj Murdoch To Greg Smith Subject Re: Powers GS> { Code for complex numbers. This is UNTESTED, I just wrote it for the } GS> { sake of this message } GS> {$N+,E+} GS> type GS> Real = Extended; I know it's untested, but I really wouldn't recommend this. Extended is a very *bad* choice of a general real type; you'd be much better off using Double. If you use Extended, you'll get all sorts of weird things happening, because the hardware implementation of Extended was intended only for temporary results - the 80x87 is inconsistent about the precision of calculations on Extendeds, the emulator library really messes them up, etc. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/04 10:06:52 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:50:18 From Dj Murdoch To Jud Mccranie Subject Re: Linked List Sorts JM> A regular sort on an array (without the array of pointer and doing JM> a lot of exchanges) will even beat the linked list sort if there JM> are enough elements. The reason is that it can always be done in JM> O( n log n) time. The linked list method will be quadratic, due JM> to the traversal of the list, although the squared term will be JM> small at first. Unless you cheat - the way I'd sort a linked list is to create an array of pointers to the elements in O( n ) time, sort the array in O( n log n) time, and then update all the pointers in the linked list in O( n ) time. Voila - an O( n log n) sort of a linked list :-). --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/04 10:06:52 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-03-92 18:53:33 From Dj Murdoch To Jud Mccranie Subject Re: Turbo Pascal..... JM> Certainly there is no way to get back the HLL source. But could JM> a decompiler give you something to work with, even in the variables JM> are x1, x2, x3, and the procs are labeled proc1, proc2, etc? That's what a disassembler does. Why bother translating the assembler to a HLL? Everybody knows assembler these days, and you'd probably get it wrong, anyways. Lots of different high level language constructs compile to the same machine language. --- Msg V3.2 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40) * Tossed by SFToss v1.00b on 92/04/04 10:06:52 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 07:06:39 From Trevor Carlsen To Jud Mccranie Subject Re: Reading from a text f TC> A great many text files are not produced using TP. JM> The method will work on ones produced by QEdit, etc... Not necessarily. QEdit allows lines of up to 512 characters. JM> ... He didn't specify what form the data was in, JM> and that matters too. Not if a BM search is used. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:41 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 08:04:11 From Trevor Carlsen To Joy Mukherjee Subject Entry To competition TC>It was for any hint, unit, program that was useful. As I no longer TC>have CLMR on my base please netmail it to me. JM> Ack! I can't netmail to Zone 3... Perhaps snail mail then? JM> One question though : I used your MS2IEEE routine in my CLMR; is that JM> legal for an entry in the contest, or in other words, does the ENTIRE JM> unit/program/... have to be completely original source code, or can we JM> borrow somebody elses code posted in the conf.? If you use code that is not yours, it is right to state your source. If it is public domain code (as all code I post here is), no permission is needed, nor by law is any acknowledgement required, to a known author. However if the author IS known, it is considered the right and proper thing to make the acknowledgement. If the code you use that is not yours is copyright, then it must be submitted by disk along with a WRITTEN authorization from the copyright owner that the source code may be publicised and used in that manner. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:41 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 09:44:44 From Trevor Carlsen To Daniel Torrey Subject Turbovision - Off Topic? DT> Is TurboVision off-topic in here yet? In any case, are there any DT> sysops in here interested in starting a TurboVision echo? As TurboVision is part of the TP6 package and as it is in Turbo Pascal, it is not off-topic. However if you wish to start a dedicated echo for it, there is nothing to stop you and it may be a very good idea. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:41 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 09:48:15 From Trevor Carlsen To Jud Mccranie Subject Text file searching JM> However, I defend my advise to the new user about using POS on JM> individual lines for several reasons. Jud, because I, or anyone else, point out a possible reason for NOT doing something in a particular way, is by no means a reason to think that we are having a cheap shot at you. Rather it is merely pointing out that it may not work "across the board". This allows the recipient to decide whether it is valid for his/her particular case. As you have probably noticed, there have been many occasions when code I have presented has received instant caveats from djm and others. That is good and as it should be in an echo such as this. The thing to remember is that such criticism is not meant in a personal way, but rather as an additional help, perhaps to both the poster and the recipient. JM> 1. The person specifically asked about searching a text file. Most JM> text files are in a format that will work with my method. He did JM> not specify the format, so it is reasonable to assume a std text file. Fine. The critical word is "most". JM> 2. He specifically asked how to find the LINE that contains the key. JM> This implies a standard text file format. The method I gave will do JM> that, whereas your B-M program gives a byte number. A line can be from 0..n characters. Otherwise I agree with your comments. JM> 4. You (correctly) said that my method wouldn't work if the key was JM> divided between lines. However, assuming a standard text file your JM> B-M program in PNL #10 won't work in that case either because of the JM> imbedded CR/LF. Correct, and I did point that out in another message. JM> 5. On normal-sized text files, your B-M program is only a small JM> fraction of a second faster than the brute-force method. Correct again... The programmer should always consider the best option for the particular case at hand. However the 255 character limitation with TP's Readln procedure is IMHO important enough to always be listed as a caveat. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:41 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 10:17:05 From Trevor Carlsen To Philippe Moroux Subject help w/search FD> Have you tried executing your piece of code? It doesn't work. TC> That code was a *working* copy of a test program. If you TC> cannot make it work then I would suggest that you are doing TC> something wrong or do not know how to use it or the message TC> you received was incomplete in some way. I have tested it TC> again in response to your statement and find it still works TC> perfectly OK. In what way does it "not work"? {$REDFACE+ ++} This is a classic illustration of incomplete testing on my part and I apologise. The code *appears* to work when the search string is in the later parts of a large file. Even then the result is not correct. If the search string is in the first 65520 bytes the result returned is indeed zero and obviously I did not test that condition. :-( The actual Boyer-Moore function is correct. The fix is in the main program: PM> repeat PM> BlockRead(f,buffer^,sizeof(buffer^),result); PM> position := BMSearch(buffer^,KeyStr,result); PM> finished := (result < sizeof(buffer^)) or (position <> $ffff); PM> if position = $ffff then PM> inc(offset,result); ^ Delete the semi colon and add the following- else inc(offset,position); PM> Strfound := position <> $ffff; PM> until finished; PM> close(f); PM> if Strfound then PM> writeln('Found at offset ',offset) PM> else PM> writeln('Not found'); PM> end. Once again, to you and especially Frank Derks my apologies. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:42 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 10:59:21 From Trevor Carlsen To Benjamin Lin Subject OPro in Oz BL> Hi, does OPRO has a version number and what is the latest? Where is it BL> available in Australia? The latest OPro I have is 1.12 and it is available in Oz thru Microway. However the price (last time I checked) is around 300-350 Oz dollars and support is close to zilch. It is a rip-off. Do what I do and deal with a US mail-order place. You should be able to land it for around AU$205. Well worth the investm nt. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:42 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 11:22:37 From Trevor Carlsen To James Digiacomo Subject Dynamic Arrays JD> I'm trying to use Dynamic arrays in TPv5.5 in the following JD> program. Its works correctly within the IDE but when I JD> compile it to and .EXE file and then run it at the DOS JD> prompt, it somehow appends garbage with the data store JD> within the array. You have not initialised the array lim^ before using it in concatenation. Dynamic arrays require extreme care when being used in this way. I believe that they are valid only when you know at runtime how many elements are needed and can make the necessary memory allocation in one hit. Any other situation would normally indicate to me that an array of pointers or a linked list is a better structure to use. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:42 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 12:43:56 From Trevor Carlsen To Max Maischein Subject Linked list sorts / Competition ?? > I'll wager that the array structure can be sorted MUCH more > quickly if the original base is unsorted. MM> Well ;-) MM> Do you want to sort the pointers in an array or what ? This is much MM> faster than traversing an existing linked list. But an entry sort MM> ( as he proposed, I think ) would be much faster because there are MM> only comparisions and no shuffles to make. But I'd like to see some MM> code about this ;-) An entry sort is still slower as the list has to be traversed once for each entry. MM> Or was I a spoilsport by guessing about your sort strategies ??? No... but you are on the right track! :-) TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:42 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 12:47:46 From Trevor Carlsen To Greg Smith Subject Linked List Sorts GS> And about an hour after I wrote the last message, I changed GS> my wager to agree with you... ;-) I wasn't thinking of an GS> array of pointers (strange when I use them a lot...), now GS> that will always be faster to sort than a linked list. Oh GS> well, at least linked lists win in the area of inserting and GS> deleting new elements (most of the time). Glad you added those four words in brackets - :-) With TP's move procedure, an array of pointers can still be faster in deleting and adding new elements. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:42 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 12:50:38 From Trevor Carlsen To Scott Sanbar Subject Keyboard Stuffing > Anyone know of any procedures available that will stuff > keyscan-codes into the keyboard buffer? SS> function StuffKey(KeyCode : word) : boolean; This is similar in function to code I have posted here previously which I had never had any difficulty with. It is also the same basic method used by Turbo Power with their TPro and OPro package which I also assume have worked for a long period with no problems. It was therefore of interest to me to see that in "Turbo Pascal 6.0 - Techniques and Utilities", Rubenking turns off interrupts before doing this. His explanati n would certainly appear to be valid - that we don't want a keyboard interrupt happening in the middle of the procedure - but in practice such a routine should never occur when that is likely. TeeCee --- TC-ED v2.01 * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644) * Tossed by SFToss v1.00b on 92/04/04 13:49:43 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 08:07:17 From Trevor Carlsen To Darren Lyon Subject Arrays And Pointers DL> I have an array of 1000 bytes, stored in broad_font DL> I have a table of twelve pointers, each pointing to DL> nothin, font_pointers DL> I have a pointer of 12 bytes, stored as registered_fonts DL> What I need to do is be able to assign font_pointers[1] DL> the address of the broad_font array, and then set DL> registered_fonts[1] to 1. How do I set up the table of DL> pointers so that they point to nothing, and then point them DL> in to my routine. I have read and reread this message of yours about a dozen times and I'm still not sure I understand exactly what you are getting at! However if I'm right in what you are trying to do, all that is needed is to set up your variables in a contiguous memory area and have one global variable point at that area. From then on everything can be determined as an offset from the start of that area. The heap would be the easiest place for this area but it not essential for this. This global variable will need to be placed in a unit that appears in the uses clause of every unit that needs it. Netmail me if I misunderstand the problem. I'm sure I can help. TeeCee --- MajikToss v0.07k * Origin: Unknown - added by MajikToss v0.07k (1:3601/14.20) * Tossed by SFToss v1.00b on 92/04/04 18:08:50 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 08:07:17 From Trevor Carlsen To Randall Smith Subject Keeping Users Happy RS> ... It works both ways. We have a "Users Advisory Committee" for RS> our vertical niche software. They tell us how they are using the RS> software & we try to make it more usable. Sometimes, they floor us RS> with how they do things, but often they are doing things the software RS> doesn't by clever use of the facilities the software DOES provide. I have only once had a user suggested improvement that I have not eventually incorporated into my system as a result of the suggestion and that was because the requested facility was already available and the user was unaware of that. Generally speaking, I find that suggestions or complaints from users are the best source of ideas for improving an application. This becomes more and more the case as the application matures. TeeCee --- MajikToss v0.07k * Origin: Unknown - added by MajikToss v0.07k (1:3601/14.20) * Tossed by SFToss v1.00b on 92/04/04 18:08:50 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 08:07:17 From Trevor Carlsen To William Westlake Subject Variables > 64k > BufType : Array[1..65592] Of Char; WW> Can't allocate that big a block on the heap. Maximum is 64k WW> minus a small amout for overhead. Where did you get that idea from ... the overhead I mean? There is no "overhead involved. The limit for any structure on the heap is 65520 bytes with TP5 and 65528 bytes with TP6. However TP will allow you to declare a structure up to 65535 bytes without complaining. The reason for the limit being < 64K is because of the way pointers are used. If a structure is bigger than the limit you stand the risk of the offset portion of the address being "integer wrapped" at runtime, thus producing what is really an out-of-range condition which cannot be caught and may cause considerable grief. Here is a little program, which is safe to run, that demonstrates what happens when using TP6 (it would probably lock TP5 up so don't try it with TP5). type BigArray = array[1..16383] of longint; BAPtr = ^BigArray; var P : BAPtr; long : ^longint; W : ^word; B : ^byte; x : word; begin new(long); new(W); new(B); new(P); long^ := 0; W^ := 0; B^ := 0; P^[16383] := $ffffffff; writeln('Long^ = ',long^,' (should be zero)'); writeln('W^ = ',W^,' (should be zero)'); writeln('B^ = ',B^,' (should be zero)'); writeln('Offset of P^[1] is ',ofs(P^[1])); for x := 16382 to 16383 do writeln('Offset of P^[',x,'] is ',ofs(P^[x])); end. Here is the output from the above (TP5 would be different and the disaster worse because TP5's heap granularity is 1 instead of TP6's 8). Long^ = 0 (should be zero) W^ = 0 (should be zero) B^ = 255 (should be zero) Offset of P^[1] is 8 Offset of P^[16382] is 65532 Offset of P^[16383] is 0 As you can see B^ is getting clobbered because of integer wrap with the offset of P^[16383]. IMHO the TP compiler should catch the error if a structure is oversize, but it doesn't. TeeCee --- MajikToss v0.07k * Origin: Unknown - added by MajikToss v0.07k (1:3601/14.20) * Tossed by SFToss v1.00b on 92/04/04 18:08:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 08:07:17 From Trevor Carlsen To Nir Livne Subject Reset In Tp 6 RB> Program trash; RB> type RB> datatype = record RB> blah:blah; RB> end; RB> datafile = file of datarecord; RB> var RB> df:datafile; RB> begin RB> assign(df,'Data.dat'); RB> reset(df) RB> write(df,data); RB> close(df); NL> You are just made too complecated way to do it NL> BTW : If you will Reset a file you won't be able to write into it !! NL> to write you must ReWrite That advice is both incorrect and dangerous. A typed file opened with reset can be both read from and written to. Any file opened with rewrite will have any previous data it contains erased. You appear to be confusing typed files with text files which need to be opened with rewrite or append in order to be written to. Rewrite erases any previous contents if the file exists or opens a new file if it does not; append writes to the end of an existing file or returns an I/O error if one does not exist. TeeCee --- MajikToss v0.07k * Origin: Unknown - added by MajikToss v0.07k (1:3601/14.20) * Tossed by SFToss v1.00b on 92/04/04 18:08:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 08:07:19 From Trevor Carlsen To J J Marquez Subject Re: Why Does This Lock Up? JJ> Normally, the very LAST thing I'd suspect wrong would be the JJ> compiler itself. However...... I cut your code out, gave it a JJ> Program Test; JJ> and executed it twice, all inside a DV window. Here's the output: JJ> Board[7,9] = 2 JJ> Board[4,2] = 2 JJ> Board[1,1] = 2 JJ> Board[7,1] = 1 JJ> Board[4,0] = 1 JJ> All done JJ> Looks as though it is running here. Bear in mind that the person posting that code did not post what his compiler switches were set to. Yours could well have been different. Even so you were very lucky, although if you are running DV on a 386 it may catch the dangerous bits. Because you only tried it twice the possible danger condition did not show up. Anybody executing code that is reported as causing the sort of problems this code was, without first checking it thoroughly, doesn't have much respect for their data and should have a very recent backup! :-) TeeCee --- MajikToss v0.07k * Origin: Unknown - added by MajikToss v0.07k (1:3601/14.20) * Tossed by SFToss v1.00b on 92/04/04 18:08:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 08:07:19 From Trevor Carlsen To Harald Harms Subject Var > 64 HH> Type BIGbuf = array[1..65535] of byte; See my other post on this subject today. The above will compile but is dangerou . If a variable of that size is the only structure on the heap and the elements 65529..65535 (TP6) or 65521..65535 (TP5) are assigned a value, you trash your stack. If there other heap variables declared before it then they are what gets clobbered instead of the stack. TeeCee --- MajikToss v0.07k * Origin: Unknown - added by MajikToss v0.07k (1:3601/14.20) * Tossed by SFToss v1.00b on 92/04/04 18:08:51 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ Conference 4 Date 04-04-92 08:07:19 From Trevor Carlsen To Harald Harms Subject Dates HH> Do you know BIG of a pain it is to calcute the difference in time if HH> you are working in hours/min/seconds??? I find it a pain, it's not HH> that its that difficult,but it's a pain. I always work with the packed HH> time format. Easy to use. I will look up the structure if you need it, HH> can't remember it of hand. But, if you subtract two packed times, you HH> will get the difference, just remember that the last one is bigger HH> than the one before, and that you can't unpack the difference... The difference in what? Subtracting two packed times will certainly NOT give any meaningful value. To find the difference in seconds between any two times, they must first be converted to the number of seconds from a common datum. TeeCee --- MajikToss v0.07k * Origin: Unknown - added by MajikToss v0.07k (1:3601/14.20) * Tossed by SFToss v1.00b on 92/04/04 18:08:51